• de productomschrijving
• de inkoopprijs
• de verkoopprijs
• de voorraad

• naam
• adres
• woonplaats
• telefoonnummer

Een bestelling wordt genoteerd op een bestelformulier (papier of online) van de beheerder van het service-centrum. Dit bestelformulier bevat:

• een bestelnummer (uniek)
• de besteldatum
• de adressering van de leverancier
• de naam van de contactpersoon binnen het service-centrum

• het bestelde aantal
• de inkoopprijs
• het totaalbedrag

• Product
• Leverancier

Er loopt nog een gegevensstroom (het bestelformulier) van het proces ‘bestel producten’ naar de bestemming ‘leverancier’. We gaan dat bestelformulier nader analyseren.

Bestelformulier.

Op het bestelformulier is het volgende te zien:

• Eén maal gegevens over de leverancier, één maal de datum, het bestelnummer en de naam van de contactpersoon.
• Voor elk van de vier bestelde producten de productcode, de omschrijving, het bestelde aantal, de inkoopprijs en het totaal.
• Eén maal het totaalbedrag van de hele bestelling.

Twee soorten gegevens
Als je het bestelformulier goed bekijkt, zie je dat er sprake is van twee soorten gegevens:

1. gegevens over de bestelling
2. gegevens over bestelde producten

• Bestelling
• Bestelregel

Dit brengt het aantal entiteittypen op vier:

• Leverancier
• Product
• Bestelling
• Bestelregel

‘Er zijn verschillende leveranciers die deze producten kúnnen leveren’.

Uit het bestelformulier blijkt dat een bepaalde leverancier meer dan één product kan leveren. Dat wijst op een veel-op-veel relatie tussen de entiteittypen Product en Leverancier, met een relatietype ‘kan leveren’. Dit deel van het ERD komt er dan als volgt uit te zien:

In dit gedeelte van het ERD ligt nu vast welke leverancier ons welke producten kán leveren. Dit is van belang want als we een bestelling willen plaatsen, moeten we wel weten bij wie we dat moeten doen.

Bestelling
Het volgende aspect betreft de bestelling zelf. Deze bestaat, zoals je al gezien hebt, uit twee delen:

1. één deel met algemene informatie over de bestelling
2. een ander deel met informatie over de bestelde producten

Cardinaliteit en optionaliteit
De cardinaliteit geeft het één-op-veel verband weer. De optionaliteit kan wel wat uitleg gebruiken. Een bestelling is alleen maar zinvol als er ten minste één product besteld wordt. Met andere woorden: een bestelling moet ten minste één bestelregel hebben. Een bestelregel heeft geen betekenis als daar geen bestelling bij hoort. We moeten immers weten bij welke leverancier het betreffende product besteld is. Vandaar dat de optionaliteit in beide gevallen 1 is.

Een bestelling heeft enerzijds een verband met een leverancier en anderzijds een verband met de bestelde producten. Die twee verbanden zie je in het complete ERD hieronder.

Het complete ERD.

Een bestelling moet geplaatst zijn bij een leverancier. Een bestelling kan bij niet meer dan één leverancier geplaatst zijn. De cardinaliteiten tussen het entiteittype Bestelling en het relatietype ‘ontvangt’ zijn dus 1,1.

Een bestelregel moet betrekking hebben op een product. Een bestelregel kan niet meer dan één product betreffen. Daarom zijn ook tussen het entiteittype Bestelregel en het relatietype ‘betreft’ de cardinaliteiten 1,1.

Tot slot kijken we naar de cardinaliteiten tussen het relatietype ‘betreft’ en het entiteittype Product. Er hoeft voor een product geen bestelling te zijn; de optionaliteit is daarom 0. Er kunnen voor een product meer bestelregels zijn (bijvoorbeeld bij verschillende leveranciers). Dit betekent dat de cardinaliteit n is.

1. Leverancier
2. Product
3. Bestelling
4. Bestelregel

• Leverancier
  • leveranciercode
  • naam, adres, postcode en woonplaats
  • telefoonnummer

• Product
  • productcode
  • productomschrijving
  • inkoopprijs
  • verkoopprijs
  • voorraad

• Bestelling
  • bestelnummer
  • besteldatum
  • leveranciercode
  • naam, adres, postcode en woonplaats
  • totaalbedrag
  • contactpersoon

• Bestelregel
  • productcode
  • productomschrijving
  • besteld aantal
  • inkoopprijs
  • totaal

Het valt op dat enkele attribuuttypen twee keer voorkomen, iets wat we in een database beslist moeten vermijden. Het gaat hier om de attribuuttypen die voorkomen in de entiteittypen Bestelling en Bestelregel. In het entiteittype Bestelling zijn dit de attribuuttypen:

• leveranciercode
• naam, adres, postcode en woonplaats

De waarden van de attribuuttypen naam, adres, postcode en woonplaats kunnen veranderen, bijvoorbeeld als de leverancier verhuist of als deze een andere naam kiest. Veranderen deze gegevens, dan zou de wijziging op ten minste twee plaatsen in de database moeten worden aangebracht:

1. één maal in de entiteit van het entiteittype Leverancier,
2. één of meer keren in entiteiten van het entiteittype Bestelling.

Dit laatste is afhankelijk van het aantal bestellingen dat geplaatst is bij de betreffende leverancier. Om dit te voorkomen laten we de attribuuttypen naam, adres, postcode en woonplaats weg uit het entiteittype Bestelling.

Het attribuuttype Leveranciercode mag ook weg omdat via het relatietype ‘ontvangt’ duidelijk is bij welke leverancier de bestelling geplaatst is.

Het entiteittype Bestelregel omvat ook een aantal attribuuttypen die al beschreven zijn bij het entiteittype Product. Dat zijn:

• productcode
• productomschrijving
• inkoopprijs

Identificatie
Wanneer deze attribuuttypen alledrie uit de beschrijving van het entiteittype Bestelregel verwijderd worden, ontstaat er een probleem met de identificatie. De enige attribuuttypen die overblijven, zijn Besteld aantal en Totaal. Die zijn niet geschikt om een entiteit van het entiteittype Bestelregel te identificeren.

Het blijkt nu dat het entiteittype Bestelregel bestaansafhankelijk is van zowel het entiteittype Bestelling als het entiteittype Product. De identificatie van het entiteittype Bestelling moet dan ook de combinatie van Bestelnummer en Productcode zijn.

Tekstuele beschrijving
De tekstuele beschrijving gaat nu luiden: